2022-12-23 Mobilfunk-Backupleitung per TELTONIKA TRB140 an LANCOM-Router
Neues Gerät
Simple Fallback-Lösung / NPTv6 / ALDI TALK Jahrespaket
Kommt es nur sehr selten zu Ausfällen, bietet sich ein Tarif an der nicht genutzten Traffic überträgt bzw. nicht verfallen läßt. Nach dem ich verifiziert hatte, das der dahinterstehende Provider O2 Telefónica sowohl IPv6-fähig ist, als auch Funkabdeckung an meinem Standort bietet, habe ich mich in einem ersten Versuch für ein ALDI TALK Jahrespaket entschieden. Dieser Prepaid-Tarif wird gelegentlich von Adli angeboten. Der ungenutzte Traffic verfällt dort erst 12 Monate nach Aktivierungsdatum. Man muss zunächst eine Aldi-SIM-Karte erwerben und aktivieren und kann darauf dann das Jahrespaket buchen. Natürlich kann man beides gleichzeitig kaufen. Die Laufzeit des Jahrespakets beginnt erst mit der Aktivierung auf der Webseite. Die Beschreibungen, wie die SIM-Karte aktiviert werden muss, waren nicht immer ganz einheitlich. So entstand kurzzeitig der Eindruck, man müsste die SIM per Smartphone und Aldi-App aktivieren. Aber nein, einfach bei alditalk.de auf "SIM aktivieren". Man kann die SIM gleich im Modem verbauen. Den einzigen wirklichen Kritikpunkt gibt es bei der Verifizierung. Dort wird POSTIDENT unterstützt. Und obwohl man per QR-Code die nötigen Daten in die Postident-App übertragen kann, ist es darin dann nicht möglich sich per elektronischen Personalausweis zu verifizieren. Obwohl die App das natürlich könnte. (Die Option kann doch unmöglich mehr kosten als die Aufwandsentschädigungen der anderen Verfahren?!)
Es folgt ein Screenshot-Dump der TRB140-Konfiguration:
Wizard:
Firmwareupdaten:
Netzwerkkonfiguration für eine optimale Zusammenarbeit mit einem Router:
NAT, da die Bridge-Modi nicht richtig funktioniert haben. Traffic hörte nach nur wenigen Pakten auf zu fließen. Da der Tarif sowieso keine öffentliche IPv4 bietet war es mir die Debugarbeit nicht wert. (Bezieht sich nur auf IPv4.)
"builtin IPv6-management" soll laut Doku für Präfix-Delegation sorgen. Der LANCOM-Router erhält per Router-Advertisement mehrere /64-Netze. Egal wie dieser Hebel steht. Meiner bisherigen Erfahrung nach ist es aber zuverlässiger wenn die Option auf beiden Interfaces aus ist. ¯\_(ツ)_/¯
Auf dem TELTONIKA TRB140 kommt OpenWRT zum Einsatz. Aus unbekannten Gründen setzt TELTONIKA das ULA-Prefix fdfd:f171:667b::/48. ULAs dürfen nicht geroutet werden. Dennoch passiert es gelegentlich das genau das versucht wird. Was natürlich scheitert.
Update 2024-07-06:
Der ULA-Eintrag wurde durch ein Firmwareupdate entfernt. Durch welche Version genau, weiß ich nicht, aber spätestens seit TRB1_R_00.07.07.3 ist er nicht mehr da. Das heißt, dieser ganze Abschnitt kann ignoriert werden. (Ich lass ihn aber stehen, falls es irgendwo ähnliche Probleme gibt.)
1. LANCOM-Router: Hat eine ULA. Was in diesem Fall wegen NPTv6 ok ist. Siehe weiter unten.
2. TRB140 LTE-Gateway: Hat eine ULA und kommt von dort nicht weiter zum ISP.
3. TRB140 LTE-Gateway: Nach einer Neuverbindung hat es eine richtige Adresse und der Datenverkehr fliest.
Das Verhalten war in meinen Augen zufällig. Häufig funktioniert es direkt nach einem Neustart richtig, später aber nicht mehr. Das ULA-Präfix kann per Weboberfläche nicht direkt abgeschaltet werden. Daher dieser Workaround:
Anschließend das Gerät neu starten. (Ungetestet, aber ich gehe mal davon aus das die /etc/config/network neu geschrieben wird, sobald man per Weboberfläche ein Netzwerk-Interface bearbeitet und damit den Workaround wieder entfernt.)
Nach dieser Änderung ist IPv6 stabil.
Optionale SMS-Thematik:
Unterstützt nur STARTTLS nicht SMTPS!
Es folgt ein Screenshot-Dump der LANCOM-Router-Konfiguration:
(Das Ganze geht natürlich auch per Webinterface, aber mir gefällt LANconfig aufgrund der automatischen Config-Sicherungen besser.)
Setup-Assistent:
Damit ist ein zweiter Internet-Zugang eingerichtet, der aber noch für nichts verwendet wird. Weswegen er z.B. im LANmonitor nicht bei den aktiven WAN-Verbindungen zusehen ist.
Im folgenden wird der zweite Internet-Zugang als Backup-Leitung konfiguriert und es folgen Detailverbesserungen bezüglich IPv6.
PD-Quelle zwingend auf Router-Advertisement stellen, da TRB140 keine Präfix-Delegation per DHCPv6 macht.
Der Setup-Assistent hat die Präfix-Quelle für das INTRANET auf die Backup-Leitung gesetzt. Das sollte man schnell zurück auf die Hauptleitung ändern.
(In diesem Beispiel also INET_ALDI zurück auf INTERNET ändern. Aufgabe der Backup-Tabelle ist es, INTERNET nur im Fehlerfall auf INET_ALDI umzustellen.)
Optional:
Zieht man jetzt den Stecker der Hauptleitung, baut sich nach fünf Sekunden die Backup-Verbindung auf. Es werden zwar zwangsläufig alle laufenden Verbindungen unterbrochen, aber nach einer Neuverbindung geht es weiter. Wird die Hauptleitung wieder verfügbar, geht alles zurück.
IPv4 ist hier schneller als IPv6, da dort erst das neue Präfix propagiert werden muss. Clients scheinen auch nicht immer gleich umzuschalten, obwohl sie die neuen Daten schon haben. Vermutlich weil die alte Route nicht zurück gezogen werden kann und erst Timeouts erreicht werden müssen. Da ist jedes OS etwas anders. Es empfiehlt sich daher auf ULAs und NPTv6 umzustellen, damit der Präfix-Wechsel entfällt. (Zugegeben, auch da muss gewartet werden bis Firewall-States abgelaufen sind.)
NPTv6
IPv6-to-IPv6 Network Prefix Translation erlaubt es z.B. im LAN ein festes Netz bzw. Präfix wie fd00::/64 (mit 192.168 vergleichbar) zu haben, welches dann Richtung Internet in das ISP-Präfix übertragen wird. Entsprechend bleibt das private interne ULA-Präfix immer gleich, selbst wenn sich das ISP-Präfix ändert. Sei es durch eine Zwangstrennung, Modemneustart oder ein Wechsel auf eine Backupleitung.
Von LANCOM gibt es dazu diesen Eintrag im LCOS Handbuch und diesen Knowledge Base Artikel. Es sind im Grunde nur diese Schritte:
Siehe auch:
Stolperfalle ULA-Präfix unter Windows
Stolperfalle bei NPTv6
Update 2026-07-24:
Wenn die “Interneteinwahl”, die logische Verbindung zum ISP, geklappt hat, die Technik des Providers wie Gateway oder DNS erreichbar sind, kann es immer noch sein dass darüber hinaus nichts geroutet wird. Das ist bei meinem Kabelanschuss von Vodafone mittlerweile die häufigste Fehlerursache. Da die Verbindung aus Sicht des Routers ja steht, wird in so einem Fall auch kein Backupfall ausgelöst. Man muss dann manuell vorübergehend das Kabel zum Kabelmodem ziehen, was ja nicht die Lösung sein kann.
Deswegen empfehle ich unbedingt, unabhängig von Einwahlmethode und ISP, sogenanntes ICMP Polling einzurichten. Damit wird die Erreichbarkeit bestimmter Ziele/Hosts, per ICMP Echo Request, überprüft. Bleiben Antworten der bis zu vier zu überprüfenden Ziele aus, wird der Backupfall ausgelöst und der Traffic fließt (in meinem Fall) über Mobilfunk. Ist eines der Zeile wieder erreichbar wird automatisch zurück geschaltet.
Die große Frage ist natürlich, was trägt man für Ziele ein? (Nichts was vom eigenen ISP gehostet wird, das ist hoffentlich klar!) Und IPv4 oder IPv6? Das muss jeder für sich klären. IPv4 ist im Grunde immer noch der Primärverkehr. Das kapiert auch jeder und wird schneller repariert. Ich hatte bei Vodafone mal einen IPv6-Ausfall an meinem Einwahlknoten von über sechs Monaten! Darum bevorzuge ich hier IPv4. Als Hosts hab ich mich für 8.8.8.8 Google und 1.1.1.1 Cloudflare entschieden. Das sind beides Konzerne die im Geld ersaufen und darum betteln das man ihre DNS-Server hernimmt. Die müssen es, als Teil eines Art Sozialvertrags wegen ihrem großen Einfluss auf das Internet, hinnehmen das da jemand grob zweimal die Minute ein Ping sendet. Die sind auch groß genug das deren potentielle Abschlatkündigung vermutlich nicht an mir vorbei ginge.
Das Ping-Intervall gibt den Prüfintervall an. Antwortet bei einer Prüfung ein Host nicht innerhalb einer Sekunde, werden weitere Echo Requests gesendet, bis die Anzahl der angegebenen Wiederholungen erreicht wurde. In dem hier abgebildeten Beispiel mit zwei Hosts, einem Ping-Intervall von 35 Sekunden und 4 Wiederholungen löst der Backupfall nach spätestens 35 + 2 * 4 = 43 Sekunden aus.
Ob das ganze Funktioniert kann man auch ganz einfach testen in dem man nicht erreichbare, bzw. nicht auf ping antwortende Adressen einträgt. (z.B. 8.8.0.8/1.1.0.1) Kaum hat man die Adressen korrigiert wird auch sofort wieder zurück geschaltet.
Homepage